docs(deploy): by-reference deploys, sealed credentials, and server-side SSH keygen (v5.2.3 / v5.2.4) - #636

Splits the shipped half of #599 out so it can merge on its own. Everything here
documents behavior in **v5.2.3** — `git tag --contains` on harper#1850's and
harper#1851's merge commits returns v5.2.3 and v5.2.4 — while #599 is gated on
harper#1849, still a draft. Accurate docs for a shipped feature should not wait
on unshipped work.

Carries the corrected text, not #599's original: the corrections that lived in
#617 are folded in here, so there is no window where the published page describes
the superseded parameter form.

- **Deploying by Reference** — `harper deploy by_ref=true`, `ref=`,
  `credential=true`. A reference pins to a resolved SHA: refs resolve from the
  local checkout, then from the remote when it is absent (a shallow CI clone
  usually has neither), and the deploy fails closed if neither can name a commit,
  because peers resolve the package independently. A ref must also name something
  a clone can fetch — `refs/heads/*` or `refs/tags/*` — so `refs/pull/123/head`
  is rejected up front even where the local checkout resolves it. A pinned SHA
  fixes the source revision, not the built artifact.
- **`credential=true`** derives the host from the package, so the credential
  always matches the clone it authenticates; an explicitly named host that does
  not match is rejected rather than silently unused.
- **GitHub Actions behavior** — the unpushed-commit check is skipped there (the
  runner's checkout is not a branch `git branch -r --contains` can see) while the
  dirty-tree warning still applies, and a `pull_request` run deploys the PR's
  head commit rather than the merge commit the runner checks out.
- **Provisioning a Deploy Credential** — `harper deploy setup=true`, the
  client-side sealing flow, the two providers it supports, and that it needs
  super_user because it calls `get_secrets_public_key` and `set_secret`.
- `reference/security/secrets.md` points its private-source section at the CLI
  flow, and `5.2.md` gains the two release-note entries.

The `revert_component` cross-reference from the credential section is deliberately
left on #599: `revert_component` is unshipped, and the build caught the dangling
anchor when it came across.

Two of gemini's three findings on #636.

The duplicate `## Configuration` in `5.2.md` is mine: extracting the two 5.2.3
release-note entries by line range swept up the following section heading with
them, so the merged file carried it twice. Removed. Extracting by heading
boundary rather than line number would have avoided it — the same lesson as the
`add_ssh_key` extraction earlier, where an off-by-one line range grabbed a
neighbouring section.

"Resolved to a commit SHA before it ships" is genuinely ambiguous — "ships" reads
as a software release in a paragraph that is otherwise about git refs. Now
"before it is sent to the cluster", which is what actually happens.

Declining the third: it asks for `<VersionBadge version="v5.2.3" />` in place of
the inline `(v5.2.3+)` in `secrets.md`. That text sits mid-sentence in prose, and
CONTRIBUTING.md is explicit — "using the component mid-sentence is awkward.
Reserve `<VersionBadge>` for standalone placement after headings." The exact patch
version it also asks for is already there.

Per @cb1kenobi: the flow also calls `grant_secret` (bin/deploySetup.ts:130,
step 5 of its header comment), which I omitted. It is equally SU-only
(utility/operation_authorization.ts:345), so the guidance was right and only the
list was short.

Worth noting the omission is not random — my own text three paragraphs above
describes the flow as five steps including grant_secret, so the call list
contradicted the flow description on the same page.